This specification relates to the use of sandboxes for secure execution of untrusted software applications.
Secure execution of software applications is important in all computer systems. For example, bugs in an application's code, bugs in third party libraries and bugs in an operating system can open up the application to a security attack. Executing a thread in a secure sandbox provided by a host might prevent untrusted code from performing malicious activities on the host. Sandboxing can allow a thread to execute in a secure environment included in a computing system. One or more applications executing on the computing system may need to execute identified untested or untrusted code securely. For example, a computing system can enable and use a secure sandbox to execute the identified untested or untrusted code. The computing system can execute the identified code separately from other code in order to prevent the identified code from performing unwanted or, in some cases, malicious tasks in the computing system. A client application running on a host computing system can set up the secure sandbox and use it to execute the identified code. The secure sandbox can monitor the execution of the thread while providing a controlled set of resources for use by the thread. For example, a sandbox can allow a client application to securely execute a thread running applications downloaded from the Internet or third party libraries. In addition, an application that accesses and uses untrusted data can be potentially open to security attacks.
A processor uses one or more interrupt descriptor tables (IDTs) to decide what to do when an interrupt occurs. In situations where more than one IDT has been created, an IDT register (IDTR) can be included in a host computing system to point to the current IDT, such as a standard or default IDT. Moreover, a device driver can modify the IDTR to instead point to another IDT, such as a custom IDT. This can allow untrusted code to operate in a secure sandbox without having access to the operating system kernel.
In some situations, in order to run untrusted code securely, a second copy is made of the operating system and a secure sandbox for executing the untrusted code is included and executed in the second copy of the operating system. This requires two versions of the operating system.
In some situations, applications running on a host computing system (e.g., anti-virus software and rootkits) may modify a system service dispatch table (SSDT) (e.g., the Windows System Service Dispatch Table included in the Windows Operating System) in order to run untrusted code in a secure sandbox. However, in order to run trusted code in the operating system kernel, the SSDT needs to be switched back to its unmodified version (the version of the SSDT the operating system kernel expects to see while executing code in the operating system kernel). Failure to switch the SSDT can result in the operating system flagging the change in the SSDT as a system error resulting in the shutdown of the host computing system.
Therefore, there exists a need to allow a host computing system to run untrusted code in a secure sandbox while allowing trusted code to execute in the operating system kernel without the possibility of the operating system flagging an error and without the need for two versions of the operating system.